In the intense competition to market computer products throughout the world, the comparative user-friendliness of hardware and software products is becoming an increasingly important factor in separating the winners from the losers. In an international, multilingual marketplace, therefore, a product's ability to communicate with users in their own native languages has begun to emerge as a matter of significant importance.
Basic to this National Language Support (NLS), as it is sometimes called, is the provision for defining the textual material which a program communicates to users, usually in the form of messages or screens, in separate files or data sets which can easily be translated into other languages. This source object is then processed, if necessary, by a special program to convert it into object code format for use by the program.
The simplest form of NLS support occurs in a single-user product, in which a language object is loaded into memory, replacing an installation-specified default, when the user selects a language. The program then uses the contents of that language object when communicating with the user.
A higher level of complexity occurs in a multi-tasking product which supports multiple users simultaneously, especially if the product is interactive. In this case the program must keep track of which language object to use for each user, and it must keep the language objects in pageable memory for efficiency.
In each of these cases the NLS function which the program must provide is fairly straight-forward. An installation must be able to obtain the language objects it needs for its users--from the product vendor, a third party, or the customer's own translation--and to make those language objects available for the program's use through product "enabling". Each user must then be able to select the language he or she wants the program to use for his or her session.
In the case of a networking product, however, the solution is not so obvious. Consider a small network consisting of nodes "E", "F", and "G", located in England, France, and Germany, respectively, and assume that each is enabled only for its own language. ##STR1##
Suppose the communications link between nodes "F" and "G" suddenly becomes inoperative while an English speaking user at node "E" is using an application at node "G" through the network. Node "F" must inform the user at node "E" that the link has become inoperative, but node "F" is not enabled for English, and the user at node "E" does not understand French.
Clearly, the node where a user enters the network must support the language the user wants to use, or the user would not be able to select the language. When the node does not support the user's language, the user can request that the installation install the language, and the installation can respond exactly as it would for a non-networking product, even to the point of providing its own translation.
Unlike a non-networking product, however, the task of providing program-to-user communications for a networking product involves more than one installation, and a large network can consist of hundreds or even thousands of installations, any of which might need to communicate with the user at one time or another.